@kaikreuzer Following the road if the minimal impact change, this might to the trick.

Looking at the user report, I have the feeling that the router is discovered both as routing device and as tunneling device.
For me that is the explanation why the device IP ends up in the field.

https://community.openhab.org/t/knx-secure-initial-implementation/134133/15

For routers, the IP field should be either empty (what you preferred before) or carry the multicast address which is quite useless unless somebody reconfigured it in ETS, which can be done via the settings tab of the backbone, unlikely). Putting the hard coded default multicast address is now removed.

I have added -r to the thing id for routers - than we do not run into trouble if both tunnel and router is detected.

Hard to test without a device at hand.

The proposed change is probably low risk.

For routers, the IP field should be either empty (what you preferred before) or carry the multicast address

FWIW, let me just comment on this as I have a different understanding here: The IP field should be empty or carry the physical IP address of the device. As for all other Things, the parameter ipAddress is meant to be the physical IP address which a device gets assigned by the DHCP server (or being statically configured). It is not meant to be a multicast or broadcast address on which the device listens additionally.

It seems that if you put the IP address for a router, it will be used as a configured multicast address. At least this is what I read from the user report. I need to check the code. But as I said, without a router at hand, I can't proceed....

If I look at the docs, I have the feeling that ipAddress has somehow been misused to carry the multicast address for routers:

It seems that if you put the IP address for a router, it will be used as a configured multicast address.

Yes, correct, and I consider this as a bug in the KNX binding as mentioned here:
"The clean solution would actually to fix the binding logic to not use the ip address, but simply to go for multicast in the case of a router type."

I didn't follow this discussion from the beginning, but from your most recent comments, it seems to share some similarities with #19516, which you might want to have a look at. In this particular case the binding had a configuration parameter for the IP address of the network interface to use for the multicast listener. This was provided initially from discovery. At the same time the IP address of the gateway itself was also configured. Therefore, configuration of the multicast IP address was useless.

@jlaur thanks for mentioning! We are aware of this, and hopefully a coming core change will give more control to the binding developer - weather or not (and for which elements) the rediscovery should overwrite stored/configured settings.
Kai has outlined the idea here: #19828 (comment)

It seems that if you put the IP address for a router, it will be used as a configured multicast address.

Yes, correct, and I consider this as a bug in the KNX binding as mentioned here: "The clean solution would actually to fix the binding logic to not use the ip address, but simply to go for multicast in the case of a router type."

The point is that the multicast address is not static (though likely the default for 99,9% of the users). You can configure in the Backbone settings in ETS:

It was explicitly mentioned in the docs for one of the routers I have been looking at.

But let's discuss those improvements later. To have it a clean way, we would probably need 2 different fields.

Yes, understood that some routers might make it configurable (although I bet no user/electrician will ever change this).
But if that should be supported in openHAB, the ipAddress parameter should not be misused for this purpose, but there should rather be a dedicated optional multicastAddress parameter.